Skip to content

Conversation

pvdrz
Copy link
Contributor

@pvdrz pvdrz commented Oct 8, 2025

This PR guarantees that ./x test --test-args="--edition XXXX" ui runs correctly with the 2015, 2018 and 2021 editions.

I don't expect this PR to hold up over time but it helps to submit further updates to the //@ edition directives of tests where we can use the new range syntax to have a more robust testing across different editions

r? @fmease


try-job: aarch64-gnu
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: test-various
try-job: armhf-gnu

@rustbot

This comment was marked as resolved.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 8, 2025
@rustbot

This comment was marked as off-topic.

@rust-log-analyzer

This comment has been minimized.

@jieyouxu jieyouxu self-assigned this Oct 9, 2025
@jieyouxu jieyouxu added the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Oct 9, 2025
@jieyouxu
Copy link
Member

jieyouxu commented Oct 9, 2025

I'll nominate this for compiler team discussion re. "we accepted the MCP for the direction in theory, here's the actual shape of the implementation" for a quick vibecheck. If team is onboard, we'll coordinate to bump the priority of this PR w.r.t. merge conflict potential.

@fmease fmease added the S-waiting-on-t-compiler Status: Awaiting decision from T-compiler label Oct 9, 2025
@fmease
Copy link
Member

fmease commented Oct 9, 2025

If team is onboard, we'll coordinate to bump the priority of this PR w.r.t. merge conflict potential.

We can do so already proactively:

@bors rollup=never p=20 (bitrot-prone, prone to conflicts in the queue; ref)

Copy link
Member

@fmease fmease Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll use this concrete test as an example but this is more of a general question / issue (to be honest, I haven't looked at any of the other test changes so far):

With only minor "meta" modifications (i.e., adjusting compiletest directives & annotations only), this test can easily run in Rust 2018, 2021 and 2024, too. So I'm wondering about the greater vision and how we should go about it procedurally:

Did you plan on going over all tests again and submitting ~medium-sized follow-up PRs that relax the edition ranges of tests (and require a bit more manual work, namely those "meta" changes)? I mean I would assume so (I can also imagine the possibility that you consider this "done" for now, hence me asking). Alternatively, we could do this now in this PR.

^ This might be of interest for the next T-compiler meeting.

Copy link
Member

@fmease fmease Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

E.g., this test can be tweaked to work in Rust 2018 and Rust 2021 via trivial revisions:

//@ revisions: e2015 e2018
//@[e2015] edition: 2015
//@[e2018] edition: 2018

plus

//[e2015]~| ERROR failed to resolve: use of unresolved module or unlinked crate `a`
//[e2018]~| ERROR failed to resolve: could not find `a` in the list of imported crates

OR

//~| ERROR failed to resolve

As for Rust 2024, we probably want to migrate the implicitly unsafe extern {} to unsafe extern {} to keep this test focused (as we probably don't want to "retest" the "extern block without unsafe" error case) but you probably know that already.

That's just for illustration, I get that you plan on doing the Rust 2024 "receptivity" in a follow-up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey yes, you're right. The idea is that once the whole test suite passes with any edition, I can start submitting patches with smaller changes, more tailored to covering each test with an appropriate range of editions.

Submitting those patches before this PR would be very annoying to review and run locally as you'd have to run only the tests that were changed.

This comment was marked as duplicate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we should keep these PRs narrowly focused, mechanical is best. Mixing different kind of changes make it super easy for unexpected changes to be accidentally done among other diffs.

@jieyouxu jieyouxu removed I-compiler-nominated Nominated for discussion during a compiler team meeting. S-waiting-on-t-compiler Status: Awaiting decision from T-compiler labels Oct 9, 2025
@jieyouxu
Copy link
Member

jieyouxu commented Oct 9, 2025

Discussed in today's compiler triage meeting #t-compiler/meetings > [weekly] 2025-10-09 @ 💬, no objections to current direction.

I'll set aside sometime this weekend and/or next weekend to do a review pass.

@pvdrz pvdrz force-pushed the pvdrz/edition-range-gating branch from 5a3a9a0 to 6e1b054 Compare October 9, 2025 23:01
@jieyouxu
Copy link
Member

@bors try

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Oct 10, 2025
Gate tests with the right edition

try-job: aarch64-gnu
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: test-various
try-job: armhf-gnu
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
  config.status: executing depfiles commands
  cargo:warning=Configuring libffi failed with exit status: 1

  --- stderr
  config.status: error: in `/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/build/libffi-sys-d4296ed6a88c5bca/out/libffi-build/aarch64-unknown-linux-gnu':
  config.status: error: Something went wrong bootstrapping makefile fragments
      for automatic dependency tracking.  If GNU make was not used, consider
      re-running the configure script with MAKE="gmake" (or whatever is
      necessary).  You can also try re-running configure with the
      '--disable-dependency-tracking' option to at least be able to build
      the package (albeit without support for automatic dependency tracking).
  See `config.log' for more details

  thread 'main' (415361) panicked at /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libffi-sys-3.3.2/build/not_msvc.rs:154:5:
  Configuring libffi: exit status: 1 (cd "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/build/libffi-sys-d4296ed6a88c5bca/out/libffi-build" && CC="cc" CFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -Wno-implicit-function-declaration" LC_ALL="C" "sh" "./configure" "--with-pic" "--disable-shared" "--disable-docs" "--prefix" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2-tools/aarch64-unknown-linux-gnu/release/build/libffi-sys-d4296ed6a88c5bca/out/libffi-root")
  stack backtrace:
     0: __rustc::rust_begin_unwind
     1: core::panicking::panic_fmt
     2: build_script_build::common::run_command
     3: build_script_build::not_msvc::configure_libffi
     4: build_script_build::not_msvc::build_and_link
     5: build_script_build::main
     6: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
[RUSTC-TIMING] crossbeam_channel test:false 0.690
Bootstrap failed while executing `--stage 2 test`
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage0/bin/cargo doc --target aarch64-unknown-linux-gnu -Zbinary-dep-depinfo -j 4 -Zroot-dir=/checkout --locked --color always --release --manifest-path /checkout/src/tools/miri/Cargo.toml -Zskip-rustdoc-fingerprint --no-deps -p miri [workdir=/checkout]` failed with exit code 101
Created at: src/bootstrap/src/core/build_steps/tool.rs:191:21
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1162:1

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 1:21:29
  local time: Fri Oct 10 13:27:26 UTC 2025
  network time: Fri, 10 Oct 2025 13:27:32 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

@rust-bors
Copy link

rust-bors bot commented Oct 10, 2025

💔 Test for 058257d failed: CI. Failed jobs:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants